1. Field of the Invention
The present invention relates to a communication control method and, more particularly, to a communication control method suitable for use in, for example, multicast communication.
2. Description of the Related Art
Recently, in distributed processing environments in which computers are interconnected over a network, multimedia applications, such as electronic teleconferencing and video on demand systems, have attracted attention. Characteristics of communications performed by such multimedia applications are that there is a real-time limitation upon data transfer, for example, data must be transmitted at a fixed rate or within a fixed time, and the same data must be efficiently transferred to a plurality of receivers at the same time.
Several protocols for reserving resources corresponding to multicast have already been proposed. Here, the resources are CPU (Central Processing Unit) processing time, a network band, a data buffer and the like. For example, ST-II (Internet Stream Protocol, Version 2) is a protocol for establishing a one-to-multiple connection. A sender proposes an optimum FlowSpec (Flow Specification) and multicasts a connection establishment request to all the receivers. Here, FlowSpec indicates data transfer properties, such as data transfer rate or permissible transmission delay, and the quantity of resources required for data transfer is calculated on the basis of a specified FlowSpec.
Each receiver sends back to the sender a maximum FlowSpec which can be ensured over the route to the sender. The sender selects a minimum-level FlowSpec from among the FlowSpecs gathered from all the receivers and transmits a connection establishment request again. In the second connection establishment request, resources are actually reserved, and an identical FlowSpec connection is established for all the receivers. This connection establishment procedure is performed each time a receiver joins or leaves.
Further, in RSVP (Resource ReSerVation Protocol), by periodically sending a tree construction request in advance using conventional multicast, a multicast tree managed by RSVP is constructed. A newly joining receiver establishes a connection with the sender by sending a connection establishment request by backtracking the constructed tree. In this method, since connection establishment is performed for each receiver, it is possible to set a different FlowSpec to each receiver. In RSVP, the established connection is reestablished dynamically rather than statically in accordance with a tree construction request which is periodically received.
However, in a conventional network protocol, since time required for data transfer varies according to the quantity of resources which can be used during data transfer, it is difficult to satisfy the real-time characteristic of data transfer. Therefore, a protocol is required by which a connection is established between the sender and the receiver, and necessary resources are reserved beforehand in accordance with a transfer request before starting transmission.
In particular, in multicast communication (one-to-multiple communication), a plurality of receivers are involved, and the connection dynamically varies during data transfer as receivers join or leave. For this reason, there is a demand for a real-time multicast protocol by which a path is shared and a connection can be established dynamically in response to a request from a receiver by setting up a connection between the sender and the receiver on a tree.
The summarized features of the above-described two protocols ST-II and RSVP are shown in FIG. 11. As shown in FIG. 11, in ST-II, since a resource reservation is repeated from a sender each time a receiver joins, the load of the connection establishment request when the receiver joins concentrates on the sender, and scalability of the number of members in the group is a problem. Further, transfer level of each receiver is adjusted to the lowest transfer level among the receivers.
Therefore, in RSVP, by. transmitting a connection establishment request from a receiver, the above-described problems are solved. However, since the route varies dynamically, ensurance of an established connection is not sufficient. Further, although handling of requests from each receiver is attempted, it is not possible to select an optimum route appropriate for the request from each receiver because the route selection itself is made by the sender.
As described above, the problems of the conventional protocol are thought to occur from the fact that route selection can be made only by the sender because the route control and resource reservation mechanisms are considered to be completely independent. However, in the existing multicast route control algorithm, in an internal process, it is possible to select a route to the sender from the receiver.